The IP-based IMT network platform (hereinafter referred to as “IP2”) is a network architecture that supports terminal mobility with both route optimization and location privacy (see “Address interchange procedure in mobility management architecture for IP-based IMT network platform (IP2)”, Manhee Jo, Takatoshi Okagawa, Masahiro Sawada, Masami Yabusaki, 10th International Conference on Telecommunications ICT'2003, Feb. 23, 2003). Fundamental to IP2 is the separation of the Network Control Layer (NCPF) and the Transport Network Layer (IP-BB). In the IP2 architecture, the NCPF controls the IP-BB. The IP-BB consists of IP routers with additional packet processing features, such as temporary packet buffering or address switching. The NCPF consists of signaling servers that command the IP-BB entities intelligently.
Mobile terminals (or mobile nodes hereinafter referred to as “MN”) are assigned permanent terminal identifiers that take the form of an IP address. In addition, MNs are assigned a routing address from the access router (AR) to which they are attached. The routing address is specific to the location of the MN, and to support location privacy, it shall not be revealed to other MNs. When the MN moves to another AR, a new routing address is allocated to it from the pool of routing addresses available at the new AR. The binding between the MN's terminal identifier (IPha: “IP home address”) and its routing address (IPra: “IP routing address”) is communicated to the NCPF by the AR. More specifically, the address is sent to the visited routing manager (VRM) of the MN that governs the MN's movement in the visited network. The VRM, in turn informs the home routing manager (HRM) of the MN about the IPra.
When a MN (MN1) wishes to send a packet to another MN (MN2), it uses MN2's IPha as the destination address in the packet and transmits the packet to its AR (AR1). AR1 (termed as the sending AR) detects that the packet is addressed to the IPha of MN2 and queries the NCPF. More specifically, it queries the HRM of MN2 about the IPra of MN2. The HRM responds to the queries, and the IPra of MN2 is stored in AR1 along with the IPha of MN2. Then, the destination address of the packet (IPha of MN2) is replaced with the IPra of MN2 and the source address (IPha of MN1) is replaced with the IPra of MN1. This operation is referred to as address switching. The packet is then delivered using traditional IP forwarding to the node that owns the IPra of MN2, that is, AR2. AR2 (the receiving AR) then replaces the destination and source addresses of the packet back to the IPha of MN2 and MN1, respectively. Finally AR2 delivers the packet to MN2.
One important function of IP2 is the AR notification. Whenever MN2 moves to a new AR, the new AR allocates a new IPra for MN2 and the VRM is notified about this new IPra. Then, the VRM updates the HRM, which, in turn, updates AR1. In fact, the HRM updates all ARs that have MNs that send packets to MN2. That is, when an AR queries the HRM about the IPra of MN1, the HRM stores the identity of the querying AR and when the IPra of MN1 changes, the HRM updates all such ARs. This behaviour is termed as the AR being subscribed for updates of a particular IP2 terminal identifier. Each query the AR makes about an IP2 terminal identifier at the HRM results in the AR being subscribed at the given HRM for the given IP2 terminal identifier.
MNs in IP2 can be in Active or Dormant state. The description above corresponds to the Active state. In this state, VRMs and HRMS track the MN's mobility and location with fine AR granularity. When the MN does not communicate for extensive periods of time, it moves or is moved to Dormant state. In this state, VRMs and HRMS remove any state for the given MN. The location of the MN is now tracked with lower granularity by a different entity, namely, the Location Manager (LM). The ARs are grouped into Location Areas (LA) that determine the granularity of location tracking in Dormant state. The MN does not inform the network as it moves from one cell to another. Instead, when the MN moves to a new LA, it informs the network. Then, it sends a location update message to one AR of the LA. In turn, the AR forwards it to the Visited LM (VLM). When a CN (Correspondent Node) wishes to send a packet to the MN, its AR sends an Inquiry to the HRM of the MN. The HRM, having no information on the MN, queries the HLM, that knows about the relationship between the current VLM and the MN. The VLM pages the MN in its current location area. Then, the MN is activated, a VRM is selected and a routing state is built in both the VRM and the HRM, which can then respond to the original Inquiry.
The problem, which this invention tries to solve, is the selection of the VRM by the AR. In other words, how do the ARs know the address of the VRM to report the arrival of a new AR and its associated IPra? Also, how do the ARs select a VRM when the MN moves from Dormant to Active state? This issue is important since the VRM manages local states of the MN. To enable seamless mobility management, the ARs shall notify the same VRM about movements of an MN. Even if a new VRM is selected (e.g., a closer one for performance reasons), the identity of the old VRM must be known to the new VRM in order to allow the transfer of the MN's context from the old VRM to the new one and to remove the tate from the old VRM.
Similarly, the selection of VLMs also constitutes an issue to be solved.
Since IP2 is a very recent development, no solutions have been published yet regarding the problems mentioned above. However, there exists some approaches available in similar protocols.
Regional Registrations described in “Mobile IP Regional Tunnel Management”, E. Gustafsson, A. Jonsson and C. Perkins, draft-ietf-mobileip-reg-tunnel-08 (work in progress), November 2003, and “Hierarchical Mobile IPv6 mobility management (HMIPv6)”, Hesham Soliman, Claude Catelluccia, Karim El Malki, Ludovic Bellier, draft-ietf-mipshop-hmipv6-02 (work in progress), Jun. 15, 2004 are also mobility protocols. However, they do not include routing managers. Node mobility is managed by the Gateway Foreign Agents (GFAs) and the Mobility Anchor Points (MAPs), respectively. Both serve as mobility aware packet forwarding entities such as ARs in case of IP2. In these protocols, the MAP or the GFA is selected by the MN. Access Routers (or Foreign Agents in case of MIPv4) advertise the address of available GFAs and MAPs in Agent Advertisement messages. This allows Mobile Nodes to select one. Each time the MN moves to a new AR, it will state its current (or newly selected) GFA and MAP in the Registration (or Binding Update in MIPv6) message. When a new GFA or MAP is selected, the MN may include information about the old one to allow context transfer.
Another trivial solution would be to statically assign one VRM to each AR and always send reports to that VRM.
There are several problems with the above two approaches.
If the MN selects the identity of the VRM, then the network has no control over the VRM selected. This is unfortunate as it prevents the network to move MNs to or away from a specific VRM. (This could be helpful, e.g., when an VRM needs to be shut down temporarily for maintenance.)
A less terminal centric approach does not let the MN select the VRM, but is nevertheless aware of the identity of its current VRM. In that case, it can explicitly tell the AR which VRM to notify. This, however, results in exposing network internals to MNs, which is highly undesirable. Moreover, it allows various sorts of attacks against the network by malicious nodes, e.g., by deliberately specifying the wrong VRM, etc.
If the AR has a pre-specified VRM that is always used for reporting, then the wrong VRM is selected if the MN moves to an AR with a different VRM configured. In this case, neither the new VRM nor the new AR has any knowledge about the identity of the old VRM. Hence, context transfer is impossible.